Multicasting is a method of forwarding streaming data to a group of interested receivers in a domain, such as a wide area network (WAN). By way of example, multicasting can be used to deliver streaming audio and/or streaming video to particular clients within the domain. Such streaming audio or video may, for instance, be used to for video conferencing purposes.
One routing protocol often used in multicasting is the protocol-independent multicast sparse mode (PIM-SM) protocol. In that protocol, unidirectional shared trees rooted at a rendezvous point (RP) are built such that the RP functions, at least initially, as an intermediary between the sender of the streaming data and the various receivers of the streaming data. In a typical scenario, a single router within the domain is designated as the RP for a given range of group multicast addresses, each of which can be used to transmit a separate stream of data. Each group multicast address can be analogized to a television channel over which particular data is broadcast. The RP router receives requests from receivers, i.e., clients within the domain, that wish to receive a data stream that will be transmitted over one of the multicast addresses. In response to the requests, the RP router transmits the data traffic received from the sender to each requesting client. In such a case, the various clients need not know the address or network identity of the sender.
Before a given router is designated as an RP, several candidate RPs (C-RPs) are designated. Multiple candidates for RP are designated in case one or more of the routers fail for some reason, for example crash or lose connection to the network.
Within PIM-SM, a single bootstrap router (BSR) is often used to inform the other routers within the domain as to which routers within the domain are C-RPs. Through use of a BSR and the associated BSR protocol, the routers within the domain can be automatically configured to recognize the C-RPs. Although the automation provided by BSRs is convenient, the use of BSRs can be disadvantageous. For example, if the BSR fails (e.g., crashes or loses network connection), the BSR cannot inform the routers within the domain as to which routers are C-RPs.
A further disadvantage associated with use of PIM BSR relates to C-RP failure. In particular, if a C-RP fails, it may take a relatively long time for each router in the domain to discover the failure. The reason for the delay in discovering a C-RP failure can be better understood with reference to a brief example. Within the BSR protocol, the BSR receives periodic messages from the C-RPs within the domain as indications that the C-RPs are still operable and are connected to the network. When a C-RP fails, however, the BSR will only discover that the C-RP is unavailable after no longer receiving messages from the C-RP. Normally, the BSR will wait a time period longer than the C-RP periodic message interval before concluding that the C-RP is no longer available. For example, the BSR may wait 2.5 times the C-RP periodic message interval before arriving to that conclusion. If the interval is, for example, one minute, the BSR may not discover that the C-RP is unavailable until 2.5 minutes have passed.
After the BSR determines that the C-RP is no longer available, the BSR will stop sending periodic messages to the other routers within the domain that confirm the availability of the C-RP. Unfortunately, those other routers will, like the BSR, only themselves conclude that the C-RP is unavailable after another extended time period (e.g., another 2.5 times the BSR periodic message interval) has passed. Assuming a one minute periodic message interval for the BSR and the 2.5 multiple, the various routers of the network may not time out the entry for the C-RP until another 2.5 minutes have passed, potentially resulting in a full 5 minutes passing after the C-RP has failed before all routers are reconfigured.